本文同步刊載於個人連載網站
Day 1 寫到，我做第一個完整產品時，並沒有經歷：
先把程式寫熟，再開始做真正的東西。
很多功能都是一邊做、一邊問 AI，一邊才補上理解。
後來我才發現，這不只改變了我寫程式的方式，也改變了我學習軟體開發的順序。
實作開始跑在理解前面。
以前如果有一件事情完全不會做，我通常會先找教學。
先知道大概有哪些概念，至少理解自己正在做什麼，才有辦法開始。
有了 AI Coding 之後，這個順序常常會反過來。
我可以先描述自己想要的結果，跟 AI 討論可以怎麼做，甚至在還不知道相關工程名詞的情況下，就先把東西一路做下去。
直到撞牆。
當時我想做的是一個 LINE bot。
最開始很簡單。
使用者傳來訊息。
系統判斷內容。
再回覆對應的罐頭訊息。
那時候我使用 n8n，也是照著 YouTube 教學一步一步做。
n8n 可以把不同步驟、條件和動作，用圖像化方式接成流程。
所以一開始很好理解。
收到訊息。
判斷內容。
回覆結果。
畫布上的節點一個接一個，看起來就像把工作流程直接畫出來。
但後來，我想做的不再只是：
收到這句話，就回覆那句話。
對話開始需要一個步驟接著一個步驟。
使用者做了第一個選擇之後，下一步要根據前面的答案決定。
中間會有不同分支。
也可能需要返回、取消或修改。
這些需求不是一次全部出現，而是一個接一個慢慢加上去。
AI 也確實可以繼續幫我做。
問題是，畫布開始越來越可怕。
很多地方做的事情很像。
為了不要讓所有流程都用大量交叉連線接在一起，我開始一直複製相似節點。
不複製，畫布會慢慢變成一張很難讀的網。
複製之後，又出現另一個問題。
同一段流程散落在很多地方。
之後只要其中一個地方要改，就得再確認還有哪些地方也需要一起改。
我那時候並不知道自己遇到的是什麼工程問題。
所以跟 AI 討論的方法也很直接。
截圖。
把已經膨脹得很誇張的 n8n 畫布截給它看。
告訴它現在卡在哪裡，哪一段不知道怎麼接，再繼續修改。
就這樣一路做到自己都快崩潰時，AI 突然跟我提到一個以前沒聽過的詞：
狀態機。
AI 開始解釋：
像這種需要記住使用者現在做到哪一步，再根據前面的狀態決定接下來要做什麼的多步驟對話，已經不只是單純：
收到訊息 → 做出回應。
它還牽涉到：
系統怎麼記住目前進度。
那時候我才第一次很明確地意識到：
原來我已經跟一個問題纏鬥很久了，卻連它叫什麼都不知道。
我一直以為自己只是在：
把功能繼續做下去。
但早就走進一個自己沒有工程語言可以描述的問題裡。
這種經驗後來並不只發生一次。
很多時候，我不是先學一個工程概念、理解定義，再找機會把它放進專案。
比較常發生的是：
先遇到一個真的想解決的問題。
先做。
再多做一點。
發現原本的方法開始變得奇怪、難改，或者越來越難理解。
然後才知道：
原來軟體開發裡早就有一套語言在描述我現在看到的東西。
這段時間的學習很像是 bottom-up。
從眼前真的想解決的問題開始，再從撞上的困難反過來補自己缺少的概念。
這也讓 AI 對我來說很難只叫做：
寫程式的工具。
當實作跑在理解前面，它有時候像協作者，一起討論下一步怎麼做、這個需求可能怎麼實現。
有時候它直接完成實作，像助理。
等我撞到一個根本不知道怎麼描述的問題，它又會變成 tutor，替那個問題補上名字和概念。
n8n 那次，這幾種角色幾乎在同一段開發過程裡不斷切換。
以前我可能要先累積更多知識，才有辦法進入這種問題。
現在，即使我還不知道「狀態機」是什麼，也不代表我完全不能開始做需要記住對話進度的功能。
我可以先做。
AI 可以先幫我接下一步。
需求再多一點，我再繼續往下推。
所以 AI 加速的不只是 Coding。
它加速的是：
實作 → 撞牆 → 發現自己缺了什麼 → 補上概念 → 再帶著新的理解繼續實作。
整個循環。
但這裡還有一個很重要的限制。
更快撞牆，不代表我就更快知道牆是什麼。
n8n 那次就是這樣。
AI 讓我在工程語言還很不足時，仍然可以把實作往前推。
但後來真正重要的學習，是我終於有一個詞，可以重新理解自己到底撞上了什麼。
知道「狀態機」之後，原本那張失控的 n8n 畫布才開始有另一種看法。
那些大量複製的節點。
越來越複雜的分支。
很難維護的連線。
不再只是：
「畫布太亂。」
而開始變成：
背後可能有一個我以前根本不知道怎麼描述的結構問題。
有了語言之後，我才比較有機會問下一個更好的問題。
這也成了我後來整理整個系列時，很重要的一個閱讀方式：
先有問題，後來才有語言。
接下來很多篇都會是這樣。
不是我先知道正確方法，再把它套進產品。
而是先真的遇到一件事。
先做。
先卡住。
再知道：
原來這裡還有一個以前不知道自己需要知道的問題。
iThome鐵人賽
看影片追技術